home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Jan 90 / MacApp.Tech$ 1⁄19⁄90 / 0466-Re Persistent Object-Jan90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.7 KB  |  55 lines  |  [TEXT/GEOL]

  1. Item    7510013                         19-Jan-90        13:08
  2.  
  3. From:   ALGER                           Alger, Jeff,VCA
  4.  
  5. To:     D4384                           US Voting Mach, Sarner, Calvin,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Re: Persistent Objects
  10.  
  11. Greg,
  12.  
  13. Your scheme is sound as far as it goes.  Methods should be dispatched properly
  14. & etc.  I will state the obvious, though: it is up to your program logic to
  15. make sure that the SwapIn method is called before any attempt to access the
  16. instance variables.  Furthermore, the reference count scheme needs further
  17. refinement: if a reference count goes to 0, should the object perhaps disappear
  18. altogether, rather than be flushed to disk?  If not, how does one know when to
  19. use the reference counter and when not to?  There are some subtleties here.
  20.  
  21. As to IsObject failing, there is a sneaky way to get around that, if you are
  22. willing to hold your nose: change the class ID to that of the superclass
  23. TFileObject when you flush it to the cache, then change it back when you read
  24. it back in!  As long as the object is at least as large as
  25. TFileObject.GetClassSize, it will pass muster (no, sadly, overriding
  26. GetClassSize will not do.)  This allows you to shrink an arbitrarily sized
  27. subclass to the size of a TFileObject.  OK, it's not pretty, but it should get
  28. the job done.  It also prevents methods of the subclass from being called while
  29. the object is out on disk, which is HIGHLY desirable behavior.
  30.  
  31. This still, as Larry Rosenstein has pointed out, is not a general solution to
  32. the persistent object problem, since it does not address persistence of methods
  33. as well as data.  That can only be done with support from the compiler and
  34. linker, which today force all possible methods to be known in advance of
  35. program execution (thereby ruling out linking new methods at run time.)  It
  36. also does not address - without great exertion by the programmer - the problem
  37. of knowing when to write out "owned" objects automatically.  This is a problem
  38. which can only be addressed through either compiler assistance or more
  39. meta-information available at run time.
  40.  
  41. Another shortcoming is that the number of handles used in memory is not
  42. reduced, only the amount of memory.  If you have large objects, this is not the
  43. primary concern.  My experience, however, has been that the number of handles
  44. can easily be the larger problem.
  45.  
  46. This is not intended to be discouraging.  Your solution addresses a wide class
  47. of problems, is innovative, and deserves further study and experimentation.
  48. Perhaps there are other tricks which can be added on top to address some of
  49. these remaining problems.  Keep plugging!
  50.  
  51. Jeff Alger
  52. KPMG Peat Marwick
  53.  
  54.  
  55.